IBIS Macromodel Task Group Meeting date: 04 March 2014 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Altera: David Banas ANSYS: * Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma * Brad Brim Kumar Keshavan Ken Willis Ericsson: Anders Ekholm Intel: * Michael Mirmak Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff Mike LaBonte Teraspeed Consulting Group: Scott McMorrow * Bob Ross The meeting was led by Bob Ross. ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Bob and Ambrish - BIRD 147 editorial work - Bob - I'm late on this one. I don't have draft 7 available to review. - Ambrish, could you send me draft 7? - Ambrish - yes. - Bob - Perhaps we will get some discussion on this later today. - Walter to send package issues outline and example to the email list. - Bob - Walter, is this AR closed? - Walter - Yes, it is closed. - Arpad to make a BIRD163 syntax version of Walter's example. - Bob - I believe this is in progress, right? - John - I believe so. ------------- New Discussion: BIRD 147 Back-channel: - Bob - Ambrish, are you prepared to continue the back-channel discussion. - Ambrish - I've received no feedback other than from Bob. - Nothing has been updated yet. - Nothing new at this time unless others have more comments. - I know Walter had noted some concerns in the last meeting. - Radek - Last time we delayed discussion on one issue. - BIRD 147 explicitly uses the AMI_parameters_out change from BIRD 128. - BIRD 128 will have to be discussed as well. - If any changes are need, they need to be made to both BIRDs. - Ambrish - What are your concerns for BIRD 128? - Radek - In its present form, BIRD 147 depends 100 percent on BIRD 128. - So we can not ratify BIRD 147 without discussion on BIRD 128. - Ambrish - Agreed. - Radek - Personally, I have doubts about whether the solution (BIRD 128) is proper. - BIRD 128 is kind of a hack, and we should avoid this type of solution. - We should explore other options. - Walter - One of the problems with alternatives is changing the C function signature. - Radek - Yes, I know. - We added the resolve function and maybe we can add other functions. - It is related to version number, so it shouldn't be an issue. - There are better solutions to the problem. - Walter - You understand the functionality we need (BIRD 128). - Could you propose an alternative BIRD? - Radek - If I could find the time. - Walter - I understand, but I'm serious and want you to submit an alternative solution. - I think we should wait for discussion on BIRD 128 until Radek has a proposal. - Bob - I have one comment on BIRD 147. - I'm concerned about the tap coefficient example. - We already have a "tap" format, so can't we use that? - Ambrish - Let me go over your email (it just arrived recently). - Bob - I didn't mention this issue in the email. - John - (BIRD 147 comment) - Under LFSR format, one of the items is a comma separated list of values. - Model makers may put whitespace next to commas. Could be an issue for parsers. - Walter - I have a question for clarification on this. - In LFSR format, are there always 3 numbers to be comma separated? - Ambrish - I think there can be more than three. Those are the taps for the... - Walter - We need a detailed definition of what that field means. - Ambrish- I agree. - We are working on pseudo code for that. - You're the second or third person asking for that clarification. - We want pseudo code so that we know bit streams will be identical. - Walter - Okay, so the document will detail that field. - John - My point is that if we require that no space be there, people will often do it. - Ambrish - We can address that. - Bob - Are these the same meanings as the taps used elsewhere? - Ambrish - No, these are for the LFSR polynomial. - Bob - We need to clarify that these taps mean something different than used elsewhere. - Ambrish - Okay. Package Modeling Direction: - Bob - Do we want to continue the discussion on package modeling direction? - Walter - One of the things I've wanted to do for several weeks is go and review all the usage models in the IBIS file for the memory package. - Only described the usage model for the first two. - Want to go through the others and see if we all agree they should be there. - Bob - Any comments related to the use model and Walter's questions, or should we wait? - Randy - Let him review it and see if we have questions. - Walter - I think it would be useful if you made me presenter. - Bob - Okay. - Walter - [sharing the memory_package.ibs file] - IO example, one terminal or port on pin and buffer side. - Power delivery model. - All ports or terminals for power and ground pins. - One for each supply signal name (one for each on die voltage). - Power deliver model - second method. - One port for every power pin, one port for every power port on each buffer. - Other flavors of PDN modeling. - Model with Die Supply pads. - One model goes from all pins to all die pads. - Another model goes from all die pads to all buffers. - Splits to two models for PDN, one for package and one for die. - EDA tool might end up combining them into one model (like the previous example). - John - I'm not objecting to either. - But both are subject to the concern about a large number of nodes for the subckt. - Could affect performance on a simulation that doesn't require all of them. - Walter - This is the way Randy wanted to be able to supply power for his memory. - A controller might have 50 times as many, and I agree with you. - Walter - Another approach, one package model per buffer. - One model per buffer/pin, or one per diff pin. - Obvious we need to support this. (this particular example uses s-parameters). - John - If these aren't s-params, it could be useful to pass a parameter like length. - Walter - That is my next use case. - Subckt instead of s-parameters with parameter passing. - Walter - I think there is no controversy on the above. - Walter - One way is to assign an interconnect model to a [Model]. - So it's a pre-layout solution. - John - This is useful if packages are identical, or identical "enough" for all DQs. - Walter - Implies all package models are the same. - One could put in typ, min, max to cover the range on that bus. - John is right. Assumption is that all interconnect models on that bus are the same. - John - Sometimes that's true, sometimes it's not. - Is the overhead of supporting a special case worth it? - Walter - It is definitely worth it. - Many vendors are already doing it. - SERDES model example from an IBIS member vendor doing it this way. - Bob - [Model] name could be [Model Selector] name for generality. - Walter - Correct. - Walter - One option is one package per [Model] type. - This is the only one of interest (i.e., contentious). - Example, package model for I/O, one for Differential_I/O, etc. - Broadband default model and default differential model could be done with this. - Has the advantage of giving us this broadband default capability. - One could have different defaults for Input, I/O, etc. - Could have coupling or cross-talk, but only for pre-layout usage. - For post layout, only uncoupled models. - Radek - Do you have precedence rules for overlapping applications? - Walter - Yes, they were outlined in the presentation at Design Con. - Hierarchy - per pin name, per [Model] name, per [Model] type. - Bob - How do we distinguish between differential vs. single-ended output? - Walter - [Diff Pin] statement tells you what is differential. - Here I'm using + and - to indicate which pin is non-inverting and inverting. - Bob - We have a single ended I/O type and a differential I/O type? - Walter - Yes, that's a syntax we can come up with. - This example model (s4p) applies to diff pins. - John - The answer to whether we can benefit from having broadband default models is that you have vendors who've found it useful? - Walter - I hate the fact that all we do is default to lumped RLC now. - John - Some of our reasons for precedence rules are historical. It adds complexity. - Brad - Quick question... - I look back at what we've got now, RLC instead of broadband. - Implicit hierarchy. - You've done something analogous here, added hierarchy. - All you've done is generalize from lumped RLC to touchstone or IBIS ISS. - If it's good to have those levels of abstraction for broadband models, why not have it for lumped RLC too? - Then you can specify the same format for all and just specify RLC, ISS, touchstone. - Walter - Yes, that's certainly an enhancement we can make. - Brad - I'd just like to not have ten different ways to describe this. - Walter - One thing could simplify it. - Instead of saying something is per [Model] type, just make it "default." - The reason I put the Input and Output there, it's really a pre-layout issue. - It's what Scott wanted - big complex model, here are my near in and far end ports. - Could just say the Input and Output are limited to the pre-layout models for Scott. - Brad - I just wanted to comment on the generality. - Walter - I totally agree. - Walter - Lots of stuff in here is because others wanted it. - Maybe use "default" and not "[Model] type" at all. - Walter - We'd be able to parameterize by length. - Here's another thing we kind of have and kind of don't have. - We have typ, min, max for lumped RLC, but not for everything else. - Here I'd like delay corner typ, fast, slow. - I think this is a chance to come up with a nice format name. - Several format ideas, delay corner, or cross talk, or list, pdf, etc. - Need corners of packages for consistency with lumped RLC. - Radek - Filename can be arbitrary, so those names aren't counted upon, right? - Walter - Yes. - Bob - Intent is still to provide typ, min(fast), max(slow)? - Walter - Notice that I'm not using "corner" here. - In AMI and IBIS corner means typ, smallest, largest (values). - Package modeling is totally independent of that, so we have to be very careful syntactically when we name that. - That should be our next step. - Walter - It's my intention to go to our subcommittee (Randy, Mike, Arpad, Walter). - Say to them, "here's what we need to support" and let's work out the syntax. - Any objections to that approach? - Do we put this in an existing section? - Bob - Are there any questions? - Brad - On the delay corner stuff here... - What you're talking about is implementing design variation. - But is it some discrete or continuous variation? - If it's discrete, how many do you allow? - If it's continuous, how do you handle that? - What you've done is list all the possibilities? Let the subcommittee sort it out? - Walter - I listed what I think are important... - [sharing "Enhanced Parameter Formats" slide from presentation] - Can consider supporting Gaussian, Integer Range, Real Range, pdf, list. - If one had DOE experiment for manufacturing distribution, could use these types. - Anyone doing DOE and yield prediction would be able to do it with these. - Brad - So basically the list you're talking about... - Then "corner" is a special list with three values. - Walter - It looks like the parameters in AMI trees. - But with a more traditional way of describing the parameters. - Brad - This is how you might represent what was in the last two lines of your example? - Walter - Yes, can't do range on s2p, but this could have been a list. - Another example had a list that had nothing to do with speed. - Walter - Traditional IBIS simulation has always had the concept of typ, min, max. - As soon as you put in list or Gaussian, that's going to put strain on EDA tools. - So, I made sure that for any value there's a way to know the typical value. - I.e., for Gaussian it's the mean. - Brad - One procedural question: - Does this larger group want to consider the scope of the generality? - Is the subcommittee of four going to make that decision? - Walter - Subcommittee won't make that decision. - We could have straw votes on each one if we wanted to. - Bob - We might take it to this committee for the straw vote. - But people can give the subcommittee some guidance. - Rather than come up with defaults, our standard syntax has been that a typical value is provided for all cases. - Bob - Six minutes to go. Any other comments on your presentation? - Walter - I'd like to do one quick thing. - Work on EMD was using parameter tree structure. - One idea was to use it for package modeling, but that has gone by the wayside. - Went back and redid an example. Looks exactly like an EBD file. - Added the ability to provide voltages to nets. - Added the concept of connections. - Instead of a path section in an EBD file, created a [spice description] section. - We may decide not to do EBD, EMD at all. - Just say in EBD we can now have SPICE descriptions instead. - Bob - You could just name the things that you need to route. - Walter - Yes, that's exactly what I did. - In the case of I/O, it specified a pull down and ground clamp reference. - They were the same, so I only referenced one of the ports. - You don't have to provide all 4 voltages to the buffer, maybe just two, for example. - Walter - In the pin list, is this a signal name or is it POWER and GND? - EBD files just have power and ground. - Memory chips have multiple power and grounds. - Randy - EBD syntax doesn't let you provide signal name. - Walter - This may mean we have to go to EMD. - Bob - I have a hard cutoff at 4. Motion to adjourn the meeting. (motion and seconded) - Bob - Okay, thanks for joining. AR: Ambrish to update BIRD 147 with Bob. AR: Mike L. needs to upload versions of BIRD 147. AR: Subcommittee will work on more package proposals. ------------- Next meeting: 11 March 2014 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives